ASIC designs are becoming more memory dependant. It is a common design practice in all market segments to embed as much memory as possible to increase the performance of the design. Even though memory content per design increases between technology nodes, maximum compilable memory macro per instance is decreasing. With these diverging factors, large memory instances are implemented through numerous smaller instances. This implementation method can create a number of issues during front-end and back-end design phases. During the front-end design phase, for example resources are required to select the correct smaller configuration to assemble the original large memory configuration. Such a phase can result in an iterative process because this technique does not take into account design priorities such as performance, density, and power considerations. Multiple implementations must be considered before selecting an approach based on the priorities of a particular design. At the back-end, using numerous small instances to form a large instance can require that designers create muxing circuitry to tie-up such instances. In addition, the higher the number of small instances utilized, the higher the routing complexity, and routing overhead that result.
To improve the turn-around-time (TAT) both at the front-end and back-end design phases, a tool that automatically selects the proper implementation of a large memory instance based on design priorities is necessary for improving design efficiency and maximizing the use of limited resources, particularly form a customer perspective
A number of problems are associated with existing approaches. For example, the lack of a user friendly automation process for assisting a designer in selecting memory instance implementation for a design based on functional memory requirements is one problem. For a given memory instance, for example, RFQs typically specify the type of memory (single, dual, two port, etc.), configuration (words×bits), and operating frequency. In a manufacturing environment, for example, is typically the responsibility of the ASIC engineer or FAE (Field Application Engineer) to determine the best implementation to meet the performance requirements while minimizing the die area. The response to the RFQ will require die area, performance, and power estimations. Note that as utilized herein the acronym “RFQ” refers generally to a “Request for Quotation” and is typically implemented as a solicitation document used in purchasing. A RFQ is requested for information. Quotes submitted in response to it are not offers that the buyer will normally accept without some confirmation or discussion with offerors.
Existing tools must be manually iterated by using different options to understand the best implementation based on the design goals. For large memory macros, for example this task becomes even more challenging, as FAEs must now determine the partition method for combining multiple instances to meet the original configuration and performance requirements. The process is tedious, time consuming, and not the efficient way to utilize FAE resources.
Although a recommended implementation method is given to the customer by the work FAEs has done, many customers are required to utilize the same process if their memory requirements change. In this case, the process is even more problematic because the customers do not have the familiarity with LSI memory compilers and tools that our FAEs do.
Other problems associated with existing solutions is the lack of a capability to input, generate, store and manage a large number of memory configurations/instances in a database and reduce TAT by automating and improving process of memory selection. Additionally, latch-based memory (LBRAM) flow for generating size, timing and power information uses a number of 3rd party tools. There is no tool to assist the designer in deciding whether particular memory configurations should be generated using SRAM or LBRAM. In addition to such problems, the overall memory selection decisions at the pre-sales stage based on design priorities: density, performance, power cannot be easily made due to the many memory compiler options. Additionally, present solutions do not provide a robust capability for “what if” and tradeoff analysis, suggestion of memory tiles for large Megabit memories. No mechanism for store memory instances in a reusable manner is presently available in the context of such existing solutions.
Current solutions are limited in scope and applicability. For example, the only current available option involves manually running a number of tools in order to generate G12/Gflx SRAM, LBRAM and G90 SRAM memory configuration data, such as, for example, Isimemory Gflx/G12 SRAM's, and Virage tools for G90 SRAM's. In such scenarios, FAE's must manually run a compiler application to generate LBRAM's, then use a complex characterization flow to generate timing and power information for the LBRAM's. Data must be manually inserted into the DieSize spreadsheet. Such a process is highly inefficient and takes a great deal of time (e.g., days), thus impacting the turn around time to get a quote back to the customer.
Determining valid compiler options to be specified to Isimemory is time consuming. Generating datasheets through current applications takes 10 times longer than through the use of extraction engines. In general, FAE's are forced to pull together information from many sources and manually enter the data into a “die size” spreadsheet.
Generating LBRAM timing data also requires 3rd party software. The flow for generating power parameters is very complex and time consuming for FAE's to run on a daily basis. Additionally, Virage tools are not available at every design center site. Because Virage tools are not yet available for general release, there also exists very little in the way of training and documentations for FAE's other than what is provided by the software supplier. Extracting data from such output files requires that certain pieces of data are estimated, rather than generated by running tools resulting in grossly inaccurate data or overestimated values. For example, SRAM power numbers are also utilized for LBRAM's. In effect, such existing solutions result in an inefficient use of the FAE, the design center and customer resources during the manufacturing process.